There is currently no simple way for low-cost IP-enabled devices to establish peer to peer security associations (SA) (shared keys and algorithms, authenticated device identities, connection info, ports and protocols) when they have not previously connected.
Pre-configuring such devices with shared keys or certificates at manufacture may be considered but this approach does not extrapolate to allow interoperation between other legacy devices or devices that have been preconfigured with different keys/certificates.
In the following discussion, the term “IP-type” SA refers to a security association between two IP-enabled peers. Examples include associations at IPSec level, TLS level, or application level.
It is possible for relatively high-end devices to establish such an SA using IPSec provided:
a) They have existing certificates or a shared key and
b) They are IP addressable and have already discovered each other's IPs. In many networks this won't apply.
A form of SA can also be established in a TLS session, provided at least one of the devices is addressable (the server) but there are similar requirements for certificates or pre-shared keys/passwords.
It is also possible for local area networks to establish a sub-IP SA either by manual assistance (loading of keys for WEP, WPA, Bluetooth PIN entry) or by unauthenticated Elliptic Curve Diffie Helman hoping there is no nearby Man In The Middle (Bluetooth v2.1 “Just Works” pairing).
There is no easy way to enforce authorization controls on such connections (e.g. a network-level policy about which devices can connect to which other devices, what protocols are supported, lifetime limits, whether the connection keys are escrowed etc.). Furthermore, there is no easy way to build IP-type SAs.
It is therefore an object of the invention to obviate or at least mitigate the aforementioned problems.